In a given setting, it is not unusual for computing operations to take place within different time-based computing realms. For example, in an automobile, information about scheduling upcoming servicing would generally be considered low priority and could be adequately processed in a non-real time manner (e.g., sub-seconds); information regarding engine temperature, being somewhat important, could be adequately processed in a near-real time manner (e.g., milliseconds); and information such as airbag deployment, which is critical, should be processed in a real time manner (e.g., microseconds).
Similarly, in a warfare environment, different types of information need to be processed within different timing realms. For instance, troop movement information could be adequately processed in a non-real time manner (e.g., sub-seconds); information regarding airborne threats may be adequately processed in a near-real time manner (e.g., milliseconds); and information related to missile navigation should be processed in a real time manner (e.g., microseconds).
Unfortunately, regardless of the application, different realms are currently architected with different technologies and methods, making later composability difficult and expensive, if not impossible. This presents challenges in environments such as “Net-Centric” architectures proposed by the Department of Defense. In Net-Centric architectures, each node of a system is plugged into the Global Information Grid (GIG) that allows sharing of resources, both data and computation. Implicit in this Net-Centric architecture is the ability to deploy individual computational components that are accessible on the GIG. These computational components offer services that are discoverable, can discover each other and are composable. For the vision of Net-Centric warfare to be achieved, nodes must not only be added to the GIG incrementally, they must add up to a greater capability, i.e., compose or aggregate.
An evolving technology that supports the provisioning of capabilities composed of services realized from stand alone components is Service Oriented Architecture (SOA). SOA requires a standardized way of describing services, the data or computations they provide and/or consume, and the mechanism for linking the providers and consumers. These standards operate across systems and components. Web Services are one example of SOA, which are being widely deployed in the development of new systems as well as in the building of systems from existing parts.
The concept of an Enterprise Service Bus (ESB) is an architectural construct that bridges the gap between different systems, communication protocols, or data formats. ESBs can broker Web Services as well as any other services in a SOA. The essential features of an ESB include: a repository in which the metadata that describes the services, suppliers and consumers resides; the mediations and their operation on the information flowing between supplier and consumer; and the discovery, routing and matching, and event processing that realize the actual dynamic, autonomic nature needed to realize a SOA.
Unfortunately, current implementations of ESBs only allow for the delivery of services in a non-real time realm (i.e., level 3 quality of services (QoS)). However, in many environments, such as a combat-based application, there may be segments that require level 1 (microsecond realm) and level 2 (millisecond realm) QoS. As such, commercial ESB products are not currently suited for combat, and other mixed realm applications. Accordingly, a need exists for a single architecture, such as an ESB type construct, that can support multiple realms, and their associated rule sets.